So if I understand your implementation correctly, the only difference is that the original formatting implementation wrote to a temp buffer and then wrote to the target with an optional padding, while your implementation skips the padding and writes directly. Does llvm optimize the buffer away or could it be optimized even more by writing directly?

r=me if there's no reason to rewrite itoa to directly write to the target.

I also wonder if it were possible to fix the original impl in Rust to be as fast as your version by adding a conditional check for whether going through the padding function is necessary.

Does llvm optimize the buffer away or could it be optimized even more by writing directly?

It cannot write directly because it writes backwards, least significant digit first.

So if I understand your implementation correctly, the only difference is that the original formatting implementation wrote to a temp buffer and then wrote to the target with an optional padding, while your implementation skips the padding and writes directly.

They both write to a (stack-allocated) temp buffer. The only difference is that theirs does all this stuff and mine doesn't.

I also wonder if it were possible to fix the original impl in Rust to be as fast as your version by adding a conditional check for whether going through the padding function is necessary.

I filed dtolnay/itoa#1 to follow up.

I added a similar library for printing floats. Note that the new library adds ".0" onto floats that are whole numbers, so we get "3.0" instead of "3". Let me know if you find this disagreeable, although RapidJSON and Jackson both write "3.0".

Also the new library writes 1.7976931348623157e308 instead of 179769313486231570000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 which seems like a good thing.

Note that the new library adds ".0" onto floats that are whole numbers, so we get "3.0" instead of "3". Let me know if you find this disagreeable, although RapidJSON and Jackson both write "3.0".

I have no particular opinion on that. We might be breaking people's unit tests, but it's perfectly valid json to add arbitrary zeros.

which seems like a good thing.

yes, definitely

lgtm, but I think we should hold off with such a user-visible change and do it together with 0.8